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Professional Systems Group Introduces AEGIS Strategic Partner Program 


Atari's North American Computing 
Market with the AEGIS Strategic 
Partner program. 

The AEGIS Strategic Partner 
program is desigiied to create a 
unir^e relation^p between Atari 
and Its key resellers and developers. 
The relationship nurtures the 
development of both vertical- 
market and cross-discipline 
solutions, resulting in a strong and 
effective national sales 
organization. 

A key part of the AEGIS Strate^c 
Partner program is the AEGB 
Symposium, a clearinghouse for the 
ideas and information that create 
powerful vertical-market solutions, 
llie AEGIS Syinposium is a two- 
day product training event with 
parodpation from botii key 
resellers and k^ devdopers. 

On August 5, 1991, the AEGIS 
Strateac Partner program was 
kicked^ witii the very tet AEGIS 
Sprnxisium, hdd at the Wtmdham 
Garden Ho^ inSurmyvale, 
California, and at the Colwell 
Polytedinical College in Cupertino, 
Caufomia. 

The symposium began at the 
Wyndham Garden Hotd with an 
overview of the organization of 
Atari Coaster, g^en by General 
Manager Greg Pratt This was 
followed by an introduction of tiie 


Morgan, designed to insure that all 
of tire dealers were familiar with all 
aspe^ of tire basic operation of 
Atari ST/TT computers, especially 
the newer machines. 


and its goals and methods, given by 
Atari Computer VJP. of Sales, Don 
MandelL Next came a discussion of 
the Independent Atari Dealer's 
Association, given by Bill Rehbock 
and an ovennew of me Atari 
Computer product line, given by 
Art Morgan. 

A training session on the system 
hardware and software was jointly 
given by Bill Rehbock and Art 


^ A atari 

VIVCOMPITO 


The afternoon of the first day of the 
symposium was devoted to a 
number of seminars covering a 
variety of topics, including Unix on 
the T1u30, Retail Sales Teouiiques, 
Seminar ^es Techniques, the Atari 
Sales Administration, and Atari 
Held Service. 

Scattered on each of the tables 
throughout the meeting ro<xn were 
anumoerofTT030c<xnputers. At 
the end of the afternoon, a product 
expmition was given. The 
p^dpating developers installed 
their software on the machines and 
spent the next several hours giving 
hands-on demonstrations to tiie 
dealers. 

Day Two of the AEGIS Symposium 
took place at two different locations. 
At the Wyndham Garden Hotel, 
Computer resellers were treated to a 
number of special training seminars 
given by the partidpating 


ISD, and Goldleaf Publishing. 

At Cogswell College, in nearby 
Cupertino, Music resellers were also 
treated to a number of special 
training seminars given^ 
partidpating devdopera, out the 
focus here was on mudc software, 
from such developers as 


Steinberg/Jones, Roland, Dr. Ts, 
C-LAB, Interval, Scorpion, and 
Hybrid Arts. 

Some developers, such as Codehead 
Software, St^Ahead, Roland, and 
Thinkware, gave seminars at both 
locations. 

Computer and Music resellers from 
all over the country attended tiie 
symposium, although (he majcnity 
were from tiie west coast region. 
Future AEGIS Symposiums will be 
at different locations across the 
country, giving more dealers and 
developers a better chaiKe to 
partidpate. 

If you are a developer andyou 
would like to become part of future 
AEGIS Syunxisiums, please contact 
BUI Rehl^at (408) ^2082. 
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Developer Report 

Gail Johnson 

Don't Be Blue Effective 08/01 /91 all developer orders will be shipp^ 
U.P5. Grouiul Label Service rather than Blue. If you require U.P.S. Blue 
(2nd day delive^) or U.P5. Red (next day delivery ), contact (Jail 
Johnson for additional cost information before you send in your prepaid 
order. Please note that the delivery service you select does not affect 
normal order processing time for Atari. Our processing time is still 
approximately five days for in-stock merchatidise. 

Thank You, ST/TT Developers! To all who responded to our requests for 
reregistration and current product information we appreciate your cards 
and letters, ^me of you even updated me twice! Theare are many 
excellent products out there. Keep up the good work! 

Notice to Canadian Developers: If you haven't yet registered with me 
personally, please do so before September 30,1991. Unclaimed 
developers will be removed from the database after that date. Contact 
me at (408) 745-2022 if you did not receive the reregistration materials 
sent out to you in July. Thank you for your cooperation. □ 


Portfolio Briefs 

J. Patton 

For Portfolio users in the field there is a keyboard cover from 
C(»npucover for the Portfolio. These covers fit over the keyboard and 
protect the machine from dirt and spills reaching the internals through 
the keyboard. Covers come in clear and anti-glare versions. Contact Ellie 
Darden at (8(X)) 874-6391 for orders only withfo the U5., or at 
(904) 862.4^ for information or orders outside the U5.. 

Since we can't poshly cover all the industry magazines which may 
feature articles/reviews on the Portfolio wifo your software/hardware, 
we would like to invite you to contact by mail, or fax articles to. Atari 
Corporation so that we may include tins in our file of review materials 
for potential customers doing research. Mail tiiem to the attention of the 
Portfolio Developer Coordinator or fax to (408) 745-2088. Those contact 
points are good for brochures as weU. 

Any VARs with quantity needs of Portfolios take note. If you can order 
twenty four per shot we are offerii^ grade B Portfolios at a price of 
$150.(X). Crade B Portfolios are returns (in mar^ cases unopened) which 
may have minor scratches <m the case All will be QA'd b^ore leaving 
Atari and will carry the normal 90 day warranty. This is a limited offer, 
contact Adam Rabbino at (408) 745-2007. □ 


Documentofion Change 

There is an error in the documentation for tiie objc_edit() function as 
described in the GEM AES manual and in the Rjdnbow TOS Release 
Notes. 

I^t if your documentation refers to an ob_ednew1 dx parameter, cross out 
all references to it Second, the ob_ed1dx parameter is supposed to be a 
pointer to the index to the next character in ttie raw text string, not the 
index itself. In the sample call, change it to ”4ob_edidx". Upon exit from 
objc_edit(), the iiKiex will be ujxiated to reflect the cursor poation after 
whatever editing was done. For those doing their own bindings, 
int_outCl] will contain this returned value. □ 
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FSMGDOS 

Developer's Package 

Registered Developers who are 
interested in progranuning for 
FSMGDOS taking advantage of 
all the new features it provides will 
be ^d to hear that F^GDOS 
progranuning materials are now 
av^ble to upon request 

Besides the outline font capabilities 
of FSMGDOS, support for bezier 
ourve functions is also included. 

If you want to receive the 
FSMGDOS Developer's information, 
please contact Gail Johnson. 

STBook/STylus 

Documentation 

Documentation on the expansion 
bus on the soon-to-be released 
STBook and Siyius computers is 
now available upon request This 
document discusses how the new 
expansion bus is different from the 
expansion connectors on older 
machines. Hease contact Gail 
Johnson to obtain this document 

New Revision of 
Pexec Cookbook 

A new revision of the Pexec 
Cookbook document is now avail- ’ . 
able, ff you don't have this 
document or the one you have is 
dated earlier than March 19, 1991, 
ffien you may want to get the 
update. 

Besides extensive information on ffie 
PexecO GEMDOS functiort there is 
also valuable info about executable 
file formats, program flag?, and 
memory allocation. To obtain the 
new version, contact Gail Johnson. 


Atari Developer News 

ATARl.RSC staff 

NEW ACSI DMA 
Document 

The Atari ACSUDMA Integration 
Guide is now available to developers 
who are working on devices for the 
ACSI port This document details 
all of foe ins and outs of using the 
ACSI DMA port found on all ST 
models to date. Be warned, 
however, that this is an intensely 
technical, hardware-oriented 
document, aiKl not for the weak of 
heart, but if you're doing something 
for ACSI, it' s probably just what 
you've always wanted. 

If you are in need of this document, 
contact Gail Johnson. (Do you 
notice a trend here, or what?) 


New Version of 
Atari Debugger 

A new version of DB is now avail- 
able. Version 3 of DB features infix 
notation (meaning that it now 
imderstands 2 + 2 instead of having 
to use 2 2), the ability for a pro- 
gram to conununicate with and send 
conunands to foe debugger through 
imbedded XBIOS functions, arxl 
more, including support for 
GST/Lattice format symbol tables. 

If you haven't tried this debugger 
b^re now, you're really missii^ 
out The new vision is available in 
foe developer sections on GEnie and 
CompuServe. 


Announcements 

If you have a new product or 
information you would like to 
atmounce to other developers for foe 
ATARI JiSC newsletter, please mail 
or fax foe information to Mike 
Fulton at (408) 745-2094 Wherever 
possible, be sure to include such 
items as price, availability, and 
where to call or write. 


There is no charge for printing these 
annoimcements, but fdease keep in 
mind that they are used on a space- 
available, first-come, first-served 
basis. 


Universal Network 
System 

Application and Design Software 
aimounces vl.l of the Umveisal 
NETwork. Universal NETwoik vl.l 
is a hardware independent software 
solution that can work with all Atari 
ST/TT network devices currently on 
foe market 

With Universal NETwork you can 
access a file server across the 
network from foe GEM Desktop or 
from within applications just like it 
was another drive on foe system. 
You can have one file server, or 
several. Users can share hard disks, 
printers, and more. 

Universal NETwork uses the LAN 
port on foe TIX)30 and Mega STE, 
and third party adapters are 
available that allow you to link up 
older machines as well 

Universal NETwork is now ship- 
ping, at the low price $219.00 for a 
two-node setup. (Hardware not 
included) Additional nodes are 
$95.00 each. 

For additional information contact 

Application Design Software 
2^ Peach Street 
Merlin, OR 97532 
(503)476KX)71. 
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Using the GEM AES Scrap Library, TAKE TWO 

Mike Fulton 


Since kst issue'e article about using the 
AES scrap functions appeared, 
discussions with various Atari 
developers has brought forth new 
considerations whidi vxarrant certain 
changes and enhancements to that 
article and the standards which it 
describes. Therefore, that article has 
been revised, and the revised article is 
included below. In order to avoid 
further confusion, the entire article is 
included, not just those parts which 
have been changed. The changes mainly 
concern three Mngs: the format of the 
specification used with scrpjeadO and 
scrp_write(); the deletion of existing 
scrap files in the clwboard directory 
when a new scrap fie is xoritten; and 
where to put scrap files when no 
clipboard directory is defined. For 
further details, pkase rmd the article. 


The GEM AES Scrap library 
provides a standard method of 
allowing data interchange between 
applications via a clipbo^ 
mechanism. At the user’s request; 
the current application will place 
data from its own document onto 
thedipboard. Later, from the same 
applk^on or a conq>letely different 
one, vdien die user requests the data 
from die dqiboard, it can be read 
back into the current document 
There are two GEM AES scrap 
library functions, scrp_read() and 
scrp_writeO. 

The Clipboard Manager 
XCONTROL panel module allows 
the user to set the system's clipboard 
folder to whatever they want, so 
diat diis folder will be specified 
when the system is booted. The 
Clipboard Manager CPX is 
documented separately from this 
article. 


Writing a 
Ciipboard item 

WORD sc_wreturn - 
scrp„write(sc_**pscrap) ; 


The scrp.writeO call establishes the 
directory used to contain clipboard 
scrap files. A normal sequence of 
events for an application to put 
something in toe clwboard would 
be: 

I> Do a sap_readO call to 
determine toe location of toe 
system's d^board folder. If no 
existing clipboard folder exists, then 
it is recommended that your 
application create a folder named 
"CLIPBRD" in the root directory of 
the system's boot drive, and then 
construct a string containing tills 
path spedficatioa 

As for as determining toe system's 
boot drive is coiKemed, if toe 
system drive map returned by the 
BIOS call DrvmapO indicates that 
drive C is available, then you should 
create toe "CLIPBRD' folder on that 
drive. Otherwise; create the folder 
on drive A or ask toe user where to 
put it 

2) Do not make assuirqrtions about 
die format of toe string you get from 
scrp_read(). Alws^ examine toe 
string and insure that you have a 
valid path specification like 
"C:\CLIFBRD\", witoout a filename 
at the end, and ending widia 
backslash. Do whatever 
manipulations are required to get 
toe string into diatforniat For 
exarrqile, if diere is a file 
specification at the end of the string 
like •G:\CLIPBRD\SCRAP.TXT", 
'dim find toe first diaracter 
following the last backslash in die 
string and change it to a NULL If 
you get a string like "GNCLIPBRD" 
widmut a trailing backslash, then do 
an FsfirstO call to check if 
*GLIPBRD" is a subdirectory, and 
then append the backslash to the 
end. 

3) An api^cation should delete any 
edsting scrap files in die clipboard 
directory before writing its own. 
This is done in order to prevent any 
possibility of an old scrap file being 
grabbed by toe next application. A 


application may create its own 
scrp_clearO function for this 
purpose. A basic example of such a 
function might be: 

void 

scrp_clearC screippath ) 
char *scrappath; 

{ 

short err 

char scrapfile[200] ; 

strcpyC scrapfile, scrappath ); 
strcatC scrapfile, "SCRAP.** ); 

err - Fsfirstf scrappath, 2 ); 
while( I err ) 

{ 

FdeleteC scrapfile ); 

err - Fsfirst( scrapfile, 2 ); 

} 

} 

This function would be passed a 
pointer to a string which contains 
toe current clipboard folder 
specification, as specified and 
determined in steps 1 &2abov& 

4) Create and write your cUpboard 
file, using at least one of die 
standard file formats given bdow. 
Clipboard files should be of die 
form "SCRAP.*" where the filename 
extension specifies the type of data 
contained widiin the file. 

The following filenames are 
reserved for the following file 
formats. Additional file formats 
may be added to the list as they 
appear. 

SCRAP.TXT — ASCn only text, with 
a CR/LF at the end of ea^ line 

SCRAPASC — ASCn only text, with 
a CR/LFattoe end of ea^ 
paragraph 

SCRAPJRTF — ASCn only text with 
formatting specified through die 
Rich Text Format defined hy 
Microsoft 

SCRAP.1WP - First Word Plus 
formatted text 

SCRAP.WP - Word Perfect 
formatted text 
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SCRAP.GEM - Standard GEM 
Metafile Graphics Image 

SCRAP JMG - Standard GEM 
Bitmapped Graphics Image 

SCRAP.TIF - Tiff (Tagged 
Interchange Kle Format) Graphics 
Image 

SCRAP£PS — Encapsulated 
Postscript File 

SCRAP.CVG — Calamus Vector 
Graphic 

SCRAPJyiF — Data Interchange 
Format - Spreadsheet/Database data 

These are not the only types of 
clipboard files that may ^ written. 

It is expected that many applications 
will want to write their own specific 
file format In this case, it is hoped 
that the details of the file format are 
made available so that it can be 
supported by other ajrplications. In 
any case, please notify Atari 
regarding the file formatfs) and 
filename extemion(s) used by your 
application 

At a bare minimum, a text-oriented 
program should always write 
SCRAP.TXT. A vector graphics- 
oriented program should dways 
write SCRAP.GEM. And a 
bitmapped graphics-oriented 
program should always write 
SCRAPJMG. However, where 
possible, your apfdication should 
write as many formats as it can 

For example, let's say you have a 
word processor named WRirETT 
that wants to create SCRAP. WIT 
clipboard files containing formatted 
text in its own format Besides 
writing the SCRAP. WIT file for its 
own fmmat it might also write 
SCRAP.TXT, SCRAP j\SC, 
SCRAPJJTF, SCRAP.l WP and any 
other text formats that it 
understands. Likewise, a graphics 
program would write dipboaid files 
for ^ of tite graphics formats that it 
understands. A vector graphics 
program might even write out a 
bitmapped image for a non-vector 
graphics program to read. 


In some cases, depending on the 
context, it may be appropriate to 
write both te)d and graphics 
formats. For example, if you are in a 
graphics program and the user has 
selected a text object to copy to the 
clipboard, tiren the application may 
want to write a SCRAP.TXT file 
containing the text from that text 
ot^ecL Or if the user is currently 
editing a text object, and chooses to 
paste from the dipboard, then it 
would be valid for the graphics 
program to look for a text dipboard 
file so that it can grab text to put into 
the text ol^ecL 

5) If you got a valid dipboard 
directory tom scrp_read() in step 1 
and no manipulations were 
necessary in step 2 in order to get 
the string into the correct format, 
then you are done. 

If you did not get a directory from 
scrp_read() and so created foe 
"CUPBRD" folder yourself, or if you 
had to manipulate foe string in step 
2, then you now need to do a 
scrp_write(} call using foe string 
obtoined at tile end of step Z 


Reading A 
Clipboard Item 

WORD sc_rreturn - 
scrp_read( sc_rpscrap ); 

The scrp_read() function returns a 
string containing foe dipboard 
directory specification. The 
sequence of events for an 
application to read an item frcxn the 
clipboard would be: 

1) Doascip_readOcalltogetfoe 
clipboard directory. If scrp_read() 
returns zero, foen foe dipboard 
folder has not been set since foe 
corrqruter was last reset If foe 
return value is nonzero, foen foe 
clipboard directory spedfication is 
returned to you. 

Do not skip step 1 because you've 
already done it once. All steps must 
be done each time you want to grab 
something off foe ^pboard. Do not 
assume foe dipboard directory will 


not change while your application is 
running. 

The scrp_read() function is defined 
as possibly returning an error code 
of zero. However, tiiis function 
currently always returns a value of 
1. Since this may change in future 
versions of GEM AES, applications 
should handle foe case of foe error 
code even if foe programmer does 
not expect to see it 

2) If scrp_read() returns an error 
code of zero, foen foe application 
should act as though notong is 
available on foe clipboard. 

3) If you get a valid string from 
scrp_read() then you need to make 
sure it is in foe correct format as 
described in Step 2 of "Writing a 
Oipboard Item”. 

4) Now you should have a pafo 
specification like "C:\CLIPBRD\". 
Now search foe clipboard directory 
for a ’SCRAP.XXX" file your 
application understands. You 
should first look for foe formats you 
understand that provide the most 
information and foen move to more 
simple formats if you don't find 
that That is, a word processor 
would want to look for SCRAP.1 WP 
before looking for SCRAP.TXT, 
because foe SCRAP.1 WP file would 
specify information about 
formatting and text styles that foe 
SCRAP.T)^ file would not □ 
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AtariST/TTQ&A 

Mike Fulton 


Q: What is the value of the _MCH 

cookie for the Mega STE? 

A: For the Mega STE, the _MCH 
cookie value is 0x00010010. The 
0x0001 in the high word means 
*SrE' Thelowword value of 0x0010 
means, 'Specifically a Mega STE" 

Remember that in most cases, the 
_MCH cookie is not what you want 
to look for. If you want to know if a 
machine supports DMA sound, you 
shouid cheA for the _SND cookie. 

If you want to know what video 
m^es are available, you should 
check for the _VDO cookie. 

Check tile _MCH cookie only for 
things that aren't represented by 
other cookies or version numbers. If 
you want to know if additional 
serial ports are present, for example, 
check the _MCH cookie. 


Q; How is the 68882 math 
ccqxrocessor on file TT030 accessed? 

A: Ihe 58882 on the TT030 operates 
as a coprocessor to the main 68030 
cpu. There are certain machine 
language instructions which it 
undeesfimds, but which the main 
68030 cpu does not When one of 
these instructions is encountered 
while running a program, the 68882 
takes over £nm fire 68030 and 
processes the instruction. From the 
program's point of view, it's just like 
the main qni understood the 
instruction all along. 

To program for tile 68882, you need 
to dfiier have an assembler which 
understands the 68881/68882 
instruction set or a hi^-4evel 
language like C or Baac which can 
generate code for the 68881/68882. 
See the other questions below for 
more information. 


Q; How is the 68881 math processor 
on the M^a STE accessed? 


A.* The 68000 cpu does not support 
the idea of a coprocessor like the 
68030 does, so foe 68881 on foe 
Mega STE is used in perijfoeral 
mode rather than coprocessor mode. 
This is a bit slower, tot still much 
faster than not tiring foe clup at all. 

Also, foe Mega STE's 68881 is used 
in exactly foe same way as the 
SFP004 add-on board for foe Mega 
ST computer, so programs written 
with foe SFP004 in mind will auto- 
matically take advantage of it Some 
third party upgrades for the ST and 
Mega series indude a 68881 option 
which works in foe same way. 

For full programming details on foe 
Mega STE's 68881 or other peri- 
pheral mode 68881 add-ons, see the 
SFP004 Programmer's Guide. If you 
do not have this document contact 
Gailjohnsoa 


Q; Will programs written for the 
SFF004 math processor board for the 
Mega ST work with the 68882 on foe 
TT030, or vice versa? 

A: Because foe TT030's 68882 is 
used a coprocessor, not as a peri- 

^fo^ra>004 wilier 

recognize the 68882 in the TT030, 
and vice versa. 

However, it is possible for a 
program to detect which type of 
. math chip is bemg used, if any, and 
take advanfoge of dfoer type. This 
uses a bit more memory, but it may 
be preferable to having sqxnate 
versions of your program file for 
each mafo diip. See foe other ques- 
tions bdow for more infonnatioa 


Q: How can a program tell if a math 
chip is installed? 

A* The first thing to do is check foe 
Cookie Jar for an_FFU cookie. This 
will indicate if a mafo chip is 
available, and if so, what kind. The 
low word of foe cookie's value 


describes software-based floating 
point mafo support Currently 
is always zero, but this may change 
inthefoture. The high wo^ 
describes the hardware floating 
point support installed in foe 
system. This is a bitmai^red flag, 
with meanings as follows; 

Bit# Desc ription If - 1 

0 - SFP004 or other peripheral 

mode 68881 

1 - Either 68881 or 68882 fpu, 

unsure which 

2 - If bit 1 - 0, then 68881 

for sure. If bit 1-1 
then 68882 for sure 

3 - 68040 built-in fpu. 

4-7 - reserved for future 
expansion 

If your software requires line-F 
floating point supp^ (for a 68881 
or 68882 as a true coprocessor), you 
should chedc the hi^ word fen: a 
value equal or greater than 2. If 
your software reqfuires peri|foeral 
mode 68881 float^ point siqrport 
check bit 0 of the higp word. 

If foe.FPU coolde is notpresori, it 
may be because the program is 
running on an older machine with 
no coolde jar installed. Refer to foe 
SFP004Dweloper's Kt for more 
information on detecting a 
peripheral mode 68881. 

Q: What ptogranuning packages 
support the ^881 and 68882? 

A* Hisoft has several packages 
which support the 68882 in the 
TTX)30, induding tire Devpac 
assembler, Ifisoft BASIC 2D, and 
Lattice C, wMch is oqrable of 
generating code for either the 68881 
in foe Mega STE or the 68882 in the 
TT030, or auto-detecting code which 
will use either type of mafo diip or 
software routines if ndtiier is 
available. 

conthued on page 8 
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Questions from peripheral designers 
dominate this Q&A colunm. Ttranks 
go out to Jim Httsler of Atari Japan 
for 1^ irruneasurable help. Many of 
th^ ^estions can be deuced 
from the Intel spedficatioru 

Q: Does tiie INT/INTA pin of our 
82c59 coiuiect to tfie EINT/EACK of 
die Portfolio? 

A; Yes, EINT/EACK are the correct 
places to connect an external 
interrupt controller. The82C59 
should be programmed to produce a 
single byte vector when EACK is 
asserted. 


Q: If so, will DTR and DEN respond 
by cycling low during EACK (low) 
in the same manner ^y do during 
the microprocessor INTA cycle (2 
pulses)? 

A: Yes, DTR and DEN are exactly 
the processor's DT/R and DEN 
sigrials. 


Q: Will EACK respond only to 
BINT and not to PF on-board 
interrupts? Any other considerations 
other dun the 40ns deis^ between 
EACK and INTA? 

A: EACK should only occur for 
external interrupt adcnowledges. 


Q; Does the lACK line respond to ■ 
only on board interrupts or also to 
external interrupts? 

A‘ LACK happens for bodt internal 
and external interrupt acknow- 
ledges. It is a budei^ (inverted) 
version of INTA. 


Q: Is it necessary to set up the 
Peripheral ID if my hardware 
doesn't use it and the OS doesn't 
need to know about it? 

A’ It is not necessary to setup PIIYs 
for a peripheral. The OS won't choke 


Portfolio Q & A 

J.Potton 


if its not there It also will not take 
any acdon to initialize the peripheral 
on its own if it does not drvd one of 
the PlDs it knows about 


Q: How do the port address 
assigiunent for a peri|dierals relate 
to an IBM PC and what range of 
addresses am I free to use? 

A; The port asagnmerrts are unique 
to DIP. The motherboard uses ports 
in the 8000H-806FH range. DIP'S 
standi peripherals are in the 
807xH range. There is no technical 
reason why you couldn't use the 
IBM 02xx-03xx range, but you 
MUST include the rrtost significant 
address bits of the I/O port in the 
decoding, which is something PC 
peripherals do not tyjncally do. 

It would be a good idea to choose 
places that would be available on a 
"normal” PC as well 

Address 807Fh should NOT be used, 
because the OS tries to read the PID 
there. 

The ONLY way port 807Fh should 
be used is to re turn a Peripheral 
Identifier (PID). Any ofiier use of 
fills port is bound to lead to 
problems. Your peripheral should 
obviously not return an alreacty 
assigned PID unless it mimics an 
existing peripheraL 

You should NOT use SOTCh, since it 
'is used for controlling external 
memory cards and peripherals with 
onboard ROMs. 

8070h-807Bh would be a better 
choice, wrifii s<»ne unassigned PID 
returned on reads of 807^ 


Q: When an interrupt occurs, the 
interrupt vector should be fiaced on 
the bus by the peripheral. 

A- Correct WhenEACIKis 
asserted, the peripheral should drive 
its desired interrupt vector onto the 


data bus. Not driving the data bus 
will result in an undefined vector 
which can't be relied on. 


Q; Can file line IINT be used 
instead of the line EINT? 

A No. ENT is really only an 
output 


Q: Regarding vectors, since 
reserved general use interrupts on 
the PC are 60H through 66H, then 
62H through 66H should be 
available on the Portfolio, right? 

A The only problem with the 6xH 
vectors is there is no real mechanism 
for claiming one... so everybody just 
assumes the one(s) they happen to 
want is (are) free. DIP took 60H and 
61H as examples. 62Handupis 
probably safe. 

Anofiier possibili^ if you just need 
four vectors is to consider using the 
low ones where PC hardware 
interrupts are normally mapped. 

The PC/XT range shouldn't be 
touched, but the PC/AT rarige of 
70H-77H would seem especially 
good candidates since it is unlikely 
for Portfolio class machines to have 
a seccmd interrupt contrdler. 

In any evenb you should use a latch 
so that software can change the most 
significant Ints of the vector, rather 
fiian hard-wiring it into your 
circuit □ 


New Online 
For 'the Portfolio 

EDHOOKS.TXT - Documentation 
which allows manipulation of file 
editor functions witii your program. 

VTLISP.ZIP - Very Uny lisp v2.0 
for the Portfolio. Modified B.J. 
Gleason. □ 
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Calendar 

of 

Upcoming Events 


September 14-15 

Southern California Atari Faire, v5.0 
Glendale Qvic Auditoiiiun 
Glendale, CA 
For details, contact 


John King Tarpinian 
< 818 ) 246 ?'^ 


at 


S^tember 21-22 
Vfest Music Expo 
Los Angeles Airport Hilton 
Los Angeles, CA 

For detaUs, contact Don Griffin or 


Than Silverlight at (213) 477-1945 


October 2-4 
Seybold Conference 
San Jose, CA 

For deb^ contact Bill Rehbock 


October 4-5 

Audio Engineeriiig Society Expo 

New York City 

For details, call (212) 661-8528 

October 12-13 
WAACEShow 


For details, leave GEnie Email to 
J.D.BAKNK, or mail request to: 
WACCE Vendor Coordinator 
C/O John D. Barnes 
7710 Chatham Rd. 

Chevy Chase, MD 20815 


October 21-25 

Fall Comdex '91 

Las Wegas Convention Center 

& Sands Convention Center 

Las Vegas, Nevada 

For details, contact Bill Rehbock 


November 15-17 
Cyber Arts International 
Pasadena, CA 
For details contact 



rArts International 
Stevens Creek Blvd. 


Cupertino, CA 95014 
(4(») 446-1105 
(408) 446-1088 -fax 


November 23-24 

Chicaco Atari Computer Show 

Chicago, IL 

For details, contact 

LanyGrauzas 

P.O.WSTSS 

Waukegan, IL 60079-8788 

(708)5ft^71 


AlariST/TTQ&A 
(Continued from page 6) 

Laser C, from Megamax, also 
features support for the 68881. 

The GNU assembler and GCC C 
compiler also supports 68881/68882 
code generation. 


Q: Where can I get progtarruning 
information on the 68030, 68881, and 
68882? 

A: I suggest the book "Program- 
ming the 68030" by Steve Williams, 
from Addison-Wesley Publishing. It 
covers both the 68030 and 68882, but 
it also notes which parts do not also 
apply to the 68000 and 68881, 
making it a good all-around 
reference. Also highly recom- 
mended are the origi^ Motorola 
programming guides, which should 
be available at most technical 
bookstores or direct from 
Motorola. □ 


Atari Computer Corporation 
1196 Borregas Ave. 
Sunnyvale, CA 94089-1 302 
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